无题
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 课程社区 |
| 这个作业的要求在哪里 | 作业要求 |
| 我在这个课程的目标是 | 凝聚整个团队通过一定的软件开发流程，在预计时间内发布”足够好”的符合用户需求的软件，并证明其是可维护和持续发展的，并在其中做出应有的贡献，提升进行软件工程开发的能力。 |
| 这个作业在哪个具体方面帮助我实现目标 | 初步完成 Alpha 阶段的开发，为后续的进一步开发提供调整依据 |
项目与团队亮点
团队成员与分工简介
团队成立之初，我们按大家的能力和兴趣初步进行了分工的划分：团队介绍
在项目进行过程中，我们根据实际情况做出了相应的调整。
| 人员 | 任务 |
|---|---|
| 彭子峻 | PM,功能设计,接口设计 |
| 王梓恒 | 运维,前后端开发,API对接 |
| 李奕宽 | 后端开发 |
| 邓智航 | 前端开发 |
| 王靖茹 | 前端开发 |
| 陈耕 | 测试,前后端开发 |
| 田锦煜 | 测试 |
项目管理
我们参照先前于[T.3] 团队项目：团队基础设施及 DevOps 准备中确定的方式，进行项目管理。
交流沟通使用 飞书 + 微信。
- 由于有同学不习惯使用飞书，
因此常常在飞书上失联，所以多了个微信群。 - 虽然能保证消息及时通知，但的确造成了信息的冗余。
代码托管在 Github 上，分前后端仓库并行开发。
对于团队例会：
- 重大事项（如决定分工与开发方向）由线下会议解决
- 出于日常进度核对的例会，通过线上的飞书会议解决
- 简单的消息对接，通过飞书+微信解决
典型用户场景
扑克爱好者
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 扑克牌爱好者A |
| 身份 | 不折不扣的扑克爱好者 |
| 用户痛点 | 1. 有好点子设计特殊的扑克牌规则，但无法实现2. 想要知道别的同好的规则 |
| 预期使用场景 | 有了好点子后在平台上通过相应的组件设计并且实现相应的规则供广大扑克牌爱好者进行游玩，同时也可以在规则市场中看到他人发布的有意思的规则并进行相应的游玩 |
| 实现该用户需求的功能 | 设计个人信息界面。设计规则构建界面。设计对局界面。设计房间交互界面。 |
场景一、用户系统
用户可以进行如下的基本用户系统操作：
- 注册
- 登录
- 修改用户基本信息：密码、用户名
场景二、房间交互系统
用户可与进行如下与房间有关的操作：
- 创建房间
- 根据房间号加入房间
- 进入房间后，设置/取消准备状态
- 对于房主，在所有玩家准备好后，开始游戏
场景三、对局界面
在房间中所有玩家准备好，且房主点击开始游戏后，所有玩家会正式进入对局界面。
- 对局界面中，可以进行出牌/不出牌操作。
- 可以查看其他玩家的名称、剩余牌数状态。
- 在对局结束后，会显示玩家的输赢结算结果。
场景四、自定义规则构建
用户可以在“创作中心”页面，访问规则构建系统，进行：
- 已有自定义规则的管理
- 新自定义规则的构建
杀手级功能
- 有一套高自由度的组件仓库，可供用户基于图形化编程，自由进行自定义规则的构建。
- 平台可以直接通过公网访问，在Web端进行联机游玩，无需App。
发布时的努力
我们的努力，主要在于项目本身的开发上。
- 设计了 30余个 自定义规则构建组件，及其对应的图形化编程语言
- 前端界面包含 10 余个主视图
- 前后端功能/单元测试达 30+ 个，覆盖所有功能场景
软件工程质量
对于项目文档：
- 在选题完成后，编写了需求文档
- 对于自定义规则系统的图形化语言编写了设计文档
- 对于前后端通信使用的 JSON 格式亦编写了说明文档
- 在如何部署、图形化语言如何使用方面的文档尚不完善，预期后续完成
对于测试：
- 在前/后端开发进度跟进后，负责测试的同学同步跟进编写单元测试。
- 除单元测试外，测试同学亦通过实际使用样例，对功能进行了验证。
- 测试对于平台各功能均有覆盖。
对于运维：
- 采用了CI/CD，实时将开发仓库主分支的代码部署至服务端
- 理由：自动化部署，减轻运维压力
宣发和用户统计
由于项目本身开发难度大，初始分工不尽合理，且后端同学的开发进度在前期严重滞后，本项目于 Alpha 阶段的预期功能的开发进度显著晚于初始计划。这导致在 Alpha 阶段的最后一周内全员赶工，未能于组员之外开展用户体验环节，亦没有用户活跃数据统计。
我们计划在 Beta 阶段，正式进行项目的宣发与用户活跃数据统计。
项目与团队总结
项目管理
团队成员的简介与个人博客地址
排序方式按照字典序
软工课上不能入睡!
在alpha阶段主要担任前后端测试和后期前后端开发的工作。
明夜无人入睡？
在alpha阶段主要担任前端框架的设计与开发的工作。
今夜无人入睡！
在alpha阶段主要担任后端框架的设计与开发的工作。
我是来上软工课的，你们要干什么！
在alpha阶段主要担任项目经理、功能设计和接口设计的工作。
楼上别害得大家上不了软工课！
在alpha阶段主要担任前后端测试的工作。
是谁没在认真上软工课！
在alpha阶段主要担任前端开发的工作。
那以前要多想！
在alpha阶段主要担任运维、后期前后端开发、API对接的工作。
团队是如何进行项目管理的
我们参照先前于[T.3] 团队项目：团队基础设施及 DevOps 准备中确定的方式，进行项目管理。
交流沟通使用 飞书 + 微信。
- 由于有同学不习惯使用飞书，
因此常常在飞书上失联，所以多了个微信群。 - 虽然能保证消息及时通知，但的确造成了信息的冗余。
代码托管在 Github 上，分前后端仓库并行开发。
对于团队例会：
- 重大事项（如决定分工与开发方向）由线下会议解决
- 出于日常进度核对的例会，通过线上的飞书会议解决
- 简单的消息对接，通过飞书+微信解决
团队的成员如何分工协作的？有什么经验教训？
团队成立之初，我们按大家的能力和兴趣初步进行了分工的划分：团队介绍
在项目进行过程中，我们根据实际情况做出了相应的调整。
| 人员 | 任务 |
|---|---|
| 彭子峻 | PM,功能设计,接口设计 |
| 王梓恒 | 运维,前后端开发,API对接 |
| 李奕宽 | 后端开发 |
| 邓智航 | 前端开发 |
| 王靖茹 | 前端开发 |
| 陈耕 | 测试,前后端开发 |
| 田锦煜 | 测试 |
不应该将后端只交给一位
崇尚古法编程的同学，对于后端的开发量没有合理的估计，且动态调整的时间不够快，希望在beta阶段能够有所改进，并且成功上线产品。
团队成员如何沟通和对接的？有什么记录留存？
对于团队沟通和对接：
- 重大事项（如决定分工与开发方向）由线下会议解决
- 出于日常进度核对的例会，通过线上的飞书会议解决
- 简单的消息对接，通过飞书+微信解决
每次线上例会都会有相应的会议截图，不时也有飞书利用ai总结的会议内容文档。每次线下例会，也都有由王梓恒同学进行拍摄的讨论沟通的照片。其余的沟通和对接都可以在相应的微信群和飞书群中得到印证。
团队如何平衡 时间/质量/资源 争取如期完成任务的？
时间方面，由于我们一开始没有沟通好接口设计等细则，导致前后端处于各开发各的状态，虽最后还是紧急通过协调对接好来，但是过程还是十分曲折，险些让项目夭折。此外，由于后端的开发同学执着于让pm设计好相应的接口规范而迟迟不开工，导致项目推进时间严重拖后，我们也意识到了这个问题，后续将增设一名后端开发人员，同时通过多开会来对齐进度，催促项目的完成。
质量方面，由于后期进度吃紧，因此项目质量并不是很好，希望beta阶段能够把项目质量提升上来。
资源方面，由于项目进度吃紧，因此，我们还没有来得及去将项目推广到潜在的用户中，这点是alpha阶段所不足的，希望在beta阶段能够完善好来。
团队项目的实际进展如何？在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？
前端燃尽图：
后端燃尽图：
虽然燃尽图如上，但是实际的工作进展与此不相符，这是因为团队成员普遍不喜欢去关闭已完成任务的issue，因此导致燃尽图的效果不好，实际进展由我们彼此沟通来把控，但是alpha阶段已经教训我们这样的方法行不通，因此，我们在beta阶段将会严格根据任务分配的时间和所完成代码质量进行相应的奖惩。
以保证燃尽图能够以较好的形式呈现。
成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | alpha阶段团队贡献得分 | 具体的, 可衡量的, 可验证的贡献 |
|---|---|---|---|
| pzj | pm、功能设计、接口设计 | 53 | 写了接口设计和功能规则定义等8个文档和写了5次博客，并为团队进行了多次展示汇报工作 |
| wzh | 运维、前后端开发、API对接 | 54 | 写了7次博客，将前后端所需相应环境在服务器部署好并开启相应的服务，将网页挂载到申请的域名上，alpha阶段赶工阶段完成了前后端规则解析逻辑的编写 |
| lyk | 后端开发 | 22 | 写了一次博客，古法手搓后端rust框架 |
| dzh | 前端开发 | 71 | 写了两次博客，设计并实现了前端框架，实现了图形化规则构建的图形展示。 |
| wjr | 前端开发 | 56 | 写了一次博客，参与前端包含用户、房间等模块的开发。 |
| cg | 测试、前后端开发 | 53 | 写了一次博客，设计并实现了大部分的测试框架，alpha阶段赶工阶段完成了用户系统和房间系统的编写。 |
| tjy | 测试 | 41 | 写了两次博客，进行了部分代码的测试。 |
用户场景
项目开发前的目标，预期的典型用户场景，预期的功能描述
扑克爱好者
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 扑克牌爱好者A |
| 身份 | 不折不扣的扑克爱好者 |
| 用户痛点 | 1. 有好点子设计特殊的扑克牌规则，但无法实现2. 想要知道别的同好的规则 |
| 预期使用场景 | 有了好点子后在平台上通过相应的组件设计并且实现相应的规则供广大扑克牌爱好者进行游玩，同时也可以在规则市场中看到他人发布的有意思的规则并进行相应的游玩 |
| 实现该用户需求的功能 | 设计个人信息界面。设计规则构建界面。设计对局界面。设计房间交互界面。 |
场景一、用户系统
用户可以进行如下的基本用户系统操作：
- 注册
- 登录
- 修改用户基本信息：密码、用户名
场景二、房间交互系统
用户可与进行如下与房间有关的操作：
- 创建房间
- 根据房间号加入房间
- 进入房间后，设置/取消准备状态
- 对于房主，在所有玩家准备好后，开始游戏
场景三、对局界面
在房间中所有玩家准备好，且房主点击开始游戏后，所有玩家会正式进入对局界面。
- 对局界面中，可以进行出牌/不出牌操作。
- 可以查看其他玩家的名称、剩余牌数状态。
- 在对局结束后，会显示玩家的输赢结算结果。
场景四、自定义规则构建
用户可以在“创作中心”页面，访问规则构建系统，进行：
- 已有自定义规则的管理
- 新自定义规则的构建
项目发布的功能（拷贝发布文档），在哪里发布了软件。
相关功能详见发布文档
在网页端发布了该软件，目前可以通过该域名来直接访问我们的软件。
项目发布后是否满足了全部典型场景？剩下的为何没有满足？
项目发布后并未满足全部典型场景，例如：现在的规则构建界面只能展示相应的规则构建流程，无法实现图形化构建出来的规则能够正常的被当作规则供用户进行游玩。
由于后端同学的进度拖慢问题，导致部分系统功能没能正常推进，以至于最后赶工阶段砍掉了一些当前较为难实现的规则，但是同时也保留了一些本地的基础规则供用户游玩。此外，就是对构建完后的图形化规则进行解析确实是一个比较有挑战性的任务，需要花费较长时间去进行打磨与调试。
因此，是团队错误的估计了该部分的工作量，从而将其置入了alpha阶段的任务中，我们将在后续的beta阶段完成该任务。
项目发布后真正符合用户需求了吗？列出目标用户使用产品的过程和评价。
由于分工的不合理原因以及部分同学的失职，导致预期的功能没能按时完成，导致最后全员赶工，因此未能完成发布后的用户体验环节，此处没有相应的数据，争取调整后续分工安排在beta阶段获取对应的用户体验。
用户日活
由于分工的不合理原因以及部分同学的失职，导致预期的功能没能按时完成，导致最后全员赶工，因此未能完成发布后的用户体验环节，此处没有相应的数据，争取调整后续分工安排在beta阶段获取对应的用户体验。
特色功能
项目的杀手级功能，与竞品相比最特色的功能展现。
- 有一套高自由度的组件仓库，可供用户基于图形化编程，自由进行自定义规则的构建。
- 平台可以直接通过公网访问，在Web端进行联机游玩，无需App。
思考一下竞品出于什么原因并没有囊括该特色功能，团队凭借什么样的优势实现了它？
我们认为对于杀手级功能1，竞品是因为其实现难度较高而望而却步的，而我们团队拥有初生牛犊不怕虎的劲头，也不用养家糊口，因此不撞南墙不回头的走上了实现该功能的道路，虽然也遇到了瓶颈。
团队成员对这些功能的自我评价如何，是否达到了预期目标，为什么？
团队成员普遍认为除了图形化构建的规则向真实可玩规则的实现功能没有达到预期目标，其他功能都达到了预期的目标。
因为我们本来是预计在alpha阶段实现我们产品的基础功能——规则构建、对局游玩和房间系统的，但是规则构建后没法正常游玩且普遍存在不可预知的bug是超出我们的预期的。
用户对这些功能的评价如何，是否认为这些功能富有特色，为什么？
由于分工的不合理原因以及部分同学的失职，导致预期的功能没能按时完成，导致最后全员赶工，因此未能完成发布后的用户体验环节，此处没有相应的数据，争取调整后续分工安排在beta阶段获取对应的用户体验。
软件工程质量
项目有完善的文档吗，是否有约定代码规范？
有相应完善的关于图形化构建过程中的组件的定义文档、前后端交互接口格式的JSON文档等。
由于开发的同学认为不需要有代码规范，因此此处我们没有进行代码规范的制定与审查。
项目是否有出现代码混乱，没有注释，没有详细文档的问题？明年的同学继续开发这个项目，会不会出现以上抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？
目前前后端都存在部分程序没有注释的情况，可能会给后续的新同学造成困恼，但是前后端均有可供启动所用的README.md文件，可以帮助指导新同学。
因此我们认为新同学只要完全按照我们的README.md文件中的环境配置和指导部署以及编译流程，那么他/她一定能够在新的机器上照样运行我们的项目。
项目是否有单元测试，测试用例数目，代码覆盖率等。
前端单元测试明细:
| 编号 | 测试文件 | 模块 | 用例数 | 覆盖重点 |
|---|---|---|---|---|
| FE-01 | src/api/__tests__/game.spec.ts |
API | 3 | 当前对局查询、出牌、跳过 |
| FE-02 | src/api/__tests__/request.spec.ts |
API | 5 | mock 延迟、token、注册请求、错误响应、网络异常 |
| FE-03 | src/api/__tests__/room.spec.ts |
API | 7 | 规则选项归一化、创建房间、加入房间、离开房间、玩家请求头、战斗路径 |
| FE-04 | src/api/__tests__/rule.spec.ts |
API | 4 | 草稿创建、更新、发布、删除、发布失败处理 |
| FE-05 | src/api/__tests__/user.spec.ts |
API | 6 | 登录、注册、当前用户、失败缓存保护、验证码和资料修改 |
| FE-06 | src/components/rule-builder/__tests__/RuleJsonPreview.spec.ts |
组件 | 9 | JSON 预览、校验提示、复制事件 |
| FE-07 | src/components/rule-builder/__tests__/RuleStructurePanel.spec.ts |
组件 | 8 | 基础信息、对象摘要、牌型列表、类和方法展示、事件触发 |
| FE-08 | src/layouts/__tests__/MainLayout.spec.ts |
布局 | 7 | 登录态导航、未登录布局、用户摘要、退出后恢复、信息同步 |
| FE-09 | src/stores/__tests__/userStore.spec.ts |
状态管理 | 14 | 登录、注册、用户名修改、密码修改、退出、当前用户、状态重置 |
| FE-10 | src/testing/__tests__/RoomCreate.spec.ts |
测试沙箱 | 2 | 创建房间表单、按钮启用 |
| FE-11 | src/testing/__tests__/RoomJoin.spec.ts |
测试沙箱 | 2 | 加入房间表单、房间号校验 |
| FE-12 | src/utils/__tests__/cardPlayRules.spec.ts |
工具函数 | 5 | 重复选牌、手牌校验、单牌识别、非法牌型、同牌型比较 |
| FE-13 | src/utils/__tests__/helpers.spec.ts |
工具函数 | 2 | 房间名归一化、房间码生成 |
| FE-14 | src/views/__tests__/About.spec.ts |
页面 | 8 | 团队页标题、介绍、成员数量、成员名称和链接 |
| FE-15 | src/views/__tests__/BattleView.spec.ts |
页面 | 2 | 结算提醒、失败结果展示 |
| FE-16 | src/views/__tests__/CreateRoomView.spec.ts |
页面 | 2 | 规则加载、创建房间、无规则校验 |
| FE-17 | src/views/__tests__/HomeView.spec.ts |
页面 | 3 | 首页内容、返回房间入口、跳转回房间 |
| FE-18 | src/views/__tests__/JoinRoomView.spec.ts |
页面 | 3 | 空房间号拦截、无密码加入、有密码加入 |
| FE-19 | src/views/__tests__/ReadyRoomView.spec.ts |
页面 | 4 | 房间摘要、准备状态、房主开局、离开房间 |
| FE-20 | src/views/__tests__/RuleBuilderView.spec.ts |
页面 | 11 | 规则构建页面、标题、副标题、面板切换、草稿按钮、JSON 坐标恢复 |
| FE-21 | src/views/__tests__/UserView.spec.ts |
页面 | 11 | 登录注册容器、标签页切换、账户信息、头像、退出、用户名和密码修改区域 |
| 合计 | 118 |
后端单元与集成测试明细:
| 编号 | 测试文件 | 模块 | 测试条目数 | 覆盖重点 |
|---|---|---|---|---|
| BE-01 | src/domain/rule_engine.rs |
规则引擎 | 1 | tiny demo 规则从开局执行到结算 |
| BE-02 | src/infrastructure/user.rs |
用户基础设施 | 1 | 密码 hash 和校验；rstest 展开为 2 个输入场景 |
| BE-03 | src/lib.rs |
基础服务 | 1 | healthcheck |
| BE-04 | tests/api/auth_flow_test.rs |
API 流程 | 5 | 登录失败、登出、查找缺失用户、状态清理 |
| BE-05 | tests/api/find_user_test.rs |
API | 5 | 用户查询、缺失用户、异常输入 |
| BE-06 | tests/api/login_test.rs |
API | 7 | 登录成功、登录失败、密码错误、输入边界 |
| BE-07 | tests/api/logout_test.rs |
API | 4 | 登出成功、重复登出、未登录登出 |
| BE-08 | tests/api/room_test.rs |
API | 5 | 房间创建、房间参数和边界 |
| BE-09 | tests/api/rule_payload_boundary_test.rs |
API | 3 | 规则 payload 空白、缺字段、合法命名边界 |
| BE-10 | tests/api/rule_test.rs |
API | 5 | 规则 payload 校验和请求处理 |
| BE-11 | tests/api/user_auth_test.rs |
API | 7 | 用户注册、重复注册、注册参数边界 |
| BE-12 | tests/api/user_test.rs |
API / Repository | 3 | 用户 fixture、repository contract |
| BE-13 | tests/rule_engine_tests.rs |
规则引擎 | 9 | 规则解析、解析边界、动作提交、回合推进、结算 |
| BE-14 | tests/websocket/multi_client_test.rs |
WebSocket mock | 6 | 多客户端加入、状态同步、事件复制 |
| BE-15 | tests/websocket/session_boundary_test.rs |
WebSocket mock | 3 | 重复加入、稳定排序、离开未知用户 |
| 合计 | 65 | rstest 参数化展开后为 66 个可执行测试用例 |
总测试样例数据:
| 统计项 | 数量 |
|---|---|
| 前端单元测试文件数 | 21 |
| 前端单元测试样例数 | 118 |
| 后端单元 / 集成测试文件数 | 15 |
| 后端测试条目数 | 65 |
| 后端参数化展开后可执行测试样例数 | 66 |
| 前后端单元测试文件总数 | 36 |
| 前后端测试条目总数 | 183 |
| 前后端可执行测试样例总数 | 184 |
项目是否采用了CI/CD，并说明理由（可选）。
项目采用 CI了，其原因是 alpha 阶段前后端改动频繁，用户、房间、规则和对局流程相互影响，需要在 push 或 Pull Request 时自动检查格式、静态问题、单元测试、构建和 E2E，降低回归风险。
我们采用了CD，在前后端仓库中设置了供发布的主分支main当其他分支将相应的阶段性成果，推到main分支上并且打上符合v.*的标签时，会自动部署到我们的服务器上，实现新版本的自动化部署，省去了不少的人力成本，提高了部署的效率。
学到的经验和教训：整个团队在Alpha阶段学到了什么，对软件工程有什么样的经验教训，Beta阶段有什么大体计划？
经验教训:
- 要合理估计工作量，进行合理分工，例如
alpha阶段错误的将一个庞大的后端交给一位崇尚古法编程的同学，导致了进度的严重拖后。且没有严格按照相应的工期对成员进行赶工，导致进度一拖再拖。 - 要多进行交流沟通，尤其体现在前后端，
alpha阶段后端同学不动手的原因就是其认为接口和通信帧的定义应该由pm来定，但又没有反复沟通表达自己的观点，因此导致进度被拖慢，等到我去询问的时候已经是项目后期，最后也只能大赶工。此外，前后端的接口对接问题也是在项目后期才慢慢解决，可能因为frb太忙了，也可能是因为大家都是新认识的，互相之间不好开口。 - 一些规范和接口等设计要提前出文档，设计好，不要边编码边设计。
beta阶段计划：
- 重新进行分工，原来运维的同学，保有原职的情况下并入后端开发中，同时对成员严格设置相应的工期
ddl，临近和超出都会由专人负责进行催工赶工。 - 多开展会议，不限于所有人参加的例会，可以是开发组小会议之类的。总之，多交流沟通，发现什么困难及时解决，进度过慢也可以及时调整人手赶进度。
- 充分进行测试并且修改测出的
bug，对于规则解析重新设计相应的文档，保证规范统一，在实现构建后的规则可玩之后稳步推进原先的beta阶段的所有计划完成的板块。
微信